Data unit sender and data unit relay device

ABSTRACT

A data unit sender and a data unit relay device are described herein which are arranged to provide a communication of data units from the data unit sender via the data unit relay device to a data unit receiver. Also, control methods are described herein for the data unit sender and the data unit relay device.

FIELD OF THE APPLICATION

The present application relates to a data unit sender and to a data unitrelay device, which are arranged to provide a communication of dataunits from said data unit sender via said data unit relay device to adata unit receiver. The application also relates to correspondingcontrol methods for the data unit sender and data unit relay device.

BACKGROUND OF THE INVENTION

The present invention basically relates to the general field of dataunit communication. In data unit communication, an amount of data isdivided into individual units, and said units are transmitted to adesired receiver over an appropriate communication path. This form ofdata communication is very well known and in wide use.

Such data units carry a variety of names in the context of differentcommunication systems and communication protocols, such as packets,frames, segments, protocol data units, etc. The term “data unit” as usedin the present specification and claims generically refers to any suchdivision of a data amount.

In order to ensure the complete transmission of data units from a senderto a receiver, a mechanism referred to as ARQ (Automatic RetransmissionreQuest) is known. When using an ARQ mechanism, the receiver of dataunits sends feedback messages to the sender, such that the sender candetermine whether sent data units were properly received, and if not, toappropriately perform retransmissions of data units.

It can also occur that the communication of data units from a givensender to a given receiver occurs via one or more relay points. Oneexample of such a situation is if a desk top computer communicates witha portable computer that has a WLAN module, where the communication ishandled via a WLAN router. Another example of such a situation is if alink layer (layer 2) communication between a sender and receiver occursover several relay points. Such connections are also referred to asmulti-hop connections.

The basic problem encountered with such multi-hop connections is how toprovide a reliable transmission of data units from the sender (i.e. thesending end-point) to the receiver (i.e. the receiving end-point). Thepaper “A comparison of Mechanisms for Improving TCP Performance overWireless Links” by H. Balakrishnan et al, Proc. ACM SIGCOMM'96,Stanford, Calif., August 1996, gives an overview of techniques fordealing with multi-hop connections that involve wireless links.

One known solution to the multi-hop problem is the provision of splitconnections. An example of this principle is shown in FIG. 1. In theexample of FIG. 1, a link layer (layer 2) communication between a sender10 and receiver 12 via a relay device 11 is considered. In order toprovide reliable transmission of layer 2 data units, a sending peer 10_2in sender 10 and a receiving peer 11_2 b in the relay device 11implement an ARQ mechanism, and furthermore a sending peer 11_2 a ofrelay device 11 and a receiving peer 12_2 of receiver 12 implementanother ARQ mechanism. In this way, the first ARQ mechanism provides forreliability from sender 10 to relay device 11, and the second ARQmechanism provides for reliability in the communication from relaydevice 11 to receiver 12. Naturally, this split connection concept isapplicable to any layer, not just the link layer.

Nonetheless, it suffers from the disadvantage that if any problems occurin the relay device 11, or a handover from the shown relay device 11 toanother relay device becomes necessary, then the entire end-to-endcommunication is in jeopardy. More specifically, it can occur that thesender 10 has completed its communication with the relay device 11, asthe correct receipt of data units at relay 11 has been acknowledged tosender 10, and thereafter a problem occurs in relay device 11, such thatsome of these data units are lost. In such an event, these data unitswill be irrevocably lost at the given protocol level (L2 in theexample), as the sender has already completed its communication andconsequently deleted the data units from its send buffer.

In order to avoid such problems, it is known to introduce sub-layering.This is shown in an example in FIG. 2. The example again relates to alink layer communication between a sender 20 and a receiver 22. In orderto provide end-to-end reliability, the link layer L2 is divided into twosub-layers, where the upper sub-layer has two peers 20_2′ and 22_2′located at the sender 20 and receiver 22, respectively. These two peersimplement their own ARQ mechanism, in order to provide forretransmission if data units of this upper sub-layer are lost on theend-to-end connection. Additionally, a lower sub-layer is provided,having respective peers 20_2 and 21_2 b between sender 20 and relaydevice 21, and 21_2 a and 22_2 between relay device 21 and receiver 22.The data units of the upper sub-layer are encapsulated or segmented intodata units of the lower sub-layer, and each lower sub-layer peer pairhas its own ARQ mechanism. Modifications of this sub-layering conceptare known, e.g. U.S. Pat. No. 5,699,367 describes a situation, where thelower sub-layer is only provided on one hop, e.g. only between sender 20and relay device 21.

Due to the end-to-end ARQ mechanism of peers 20_2′ and 22_2′, problemsin the relay device 21 do not lead to irrevocable data unit loss. On theother hand, the ARQ mechanisms on the hops from sender to relay deviceand relay device to receiver ensure resource efficient and fast errorrecovery over each hop, e.g. by avoiding unnecessary end-to-endretransmissions. Nonetheless, the concept of sub-layering has thedisadvantage of requiring complicated adjustment of the ARQ control inthe upper sub-layer and lower sub-layer, in order to avoid ARQconflicts, which can e.g. lead to unnecessary redundant datatransmission, which in turn degrades the end-to-end performance.

WO 03/069837 A1 describes a method for retransmission of packets in abase station sub-system. A BSC communicates with an MS via a BTS, wherethe BSC and BTS are connected over a transport network. The BSC and theBTS use the GSL protocol on the physical layer. On the other hand, theBSC and the MS are RLC peers. It is disclosed to provide two types ofmessages between the BSC and the BTS: a first message format thatcomprises a data block, and a second format that only uses headersbut'does not comprise a data block. In this way, the message of thesecond format identifies a data block, but does not carry the datablock. Moreover, the BTS stores the data blocks that it successfullyreceives. The BTS also forwards these data blocks to the MS. If the MSdoes not receive a data block correctly, this is identified with thehelp of a NACK message sent in response to a polling signal. Two basicalternatives are described, where the first alternative is such that theBTS sends reception status messages in response to a polling signal, inorder to inform the BSC. In this first alternative, the BTS passes theACKs/NACKs sent by the MS to the BSC without any processing. The BSCdoes not need to send a message of the first format (with data block),as it is sufficient to send a message of the second format (without datablock), such that the BTS can identify the missing data block andperform the retransmission, without having to again send the data blockover the transport network.

On the other hand, if a reception status messages sent by the BTS to theBSC indicates a missing data block, then the BSC retransmits a messageof the first format (i.e. with the missing data block). The BSC iscontrolled in such a way that if a NACK from the MS arrives, the BSCknows that this is due to an error in the transport network and has beencorrected by an appropriate retransmission. After having received ACKmessages from the MS, the BSC sends clear messages to the BTS, such thatthe BTS removes corresponding data blocks from its memory. In the secondalternative, the BTS does not confirm a successful reception of datablocks, but only requests retransmissions of data blocks that have notbeen correctly received. In this second alternative the BTS must itselftake care of the maintenance of its memory and it will not be the BSCthat controls the removal of stored data blocks in the memory of theBTS. Namely, the BTS waits for acknowledgment messages 332 from the MSand interprets these messages. If a NACK is received from the MS, theBTS first checks whether it has the corresponding data block in itsmemory, and retransmits the data block if it is available. If it is notavailable, then the BTS requests the retransmission of the missing datablock from the BSC. The BTS also forwards the NACK. In this way the BSCcan respond in one of two ways: if it receives the NACK and aretransmission request, it sends a message of the first format (withdata block), otherwise it sends a message of the second format (withoutthe data block).

OBJECT OF THE INVENTION

The object of the invention is to provide an improved concept forreliable data unit transmission from a sender to a receiver via a relaydevice.

SUMMARY OF THE INVENTION

This object is solved by a data unit sender, data unit relay device,method of controlling a data unit sender, method of controlling a dataunit relay device and communication protocol as described in theindependent claims. Advantageous embodiments are described in thedependent claims.

The basic concept of the present invention is shown in FIG. 3. Inaccordance with the present invention a data unit communication betweena sender 30 and a receiver 32 via a relay device 31 is handled in onelayer, where the sender 30 comprises a sending peer 30_2 and thereceiver 32 a receiving peer 32_2, and the relay device 31 carries arelay peer 31_2. The communication occurs in accordance with acommunication protocol for the sending peer, relay peer and receivingpeer, where this communication protocol has a feed-back mechanism, andthe feed-back messages are such that they carry information on thereceipt of data units. The communication protocol provides for at leasta first type and a second type of receipt information, where the firsttype of receipt information is indicative of a correct receipt of a dataunit at the relay peer (31_2 in the example of FIG. 3) and the secondtype of receipt information is indicative of a correct receipt of a dataunit at the final destination peer (32_2 in the example of FIG. 3) ofthe protocol. The sending peer (30_2 in the example of FIG. 3) performsa first retransmission control procedure for a sent data unit for whichno first type receipt information has been received, and a secondreceipt retransmission control procedure for a sent data unit if thefirst type receipt information has been received. Namely, looking at theexample of FIG. 3, not having received first type receipt informationmeans that the relay peer 31_2 has not acknowledged correct receipt. Onthe other hand, receiving the first receipt information means that therelay peer 31_2 has acknowledged correct receipt. Nonetheless, thesender holds a data unit in its buffer at least until having receivedthe second type of receipt information, namely information thatindicates that the data unit in question has been received at the finaldestination (receiving peer 32_2 in the example of FIG. 3).

The relay peer of the invention is arranged to on the one hand sendsender-side feedback messages to the sending peer (30 in the example ofFIG. 3), which feedback messages provide the first type of receiptinformation when a data unit was correctly received from the sendingpeer 30_2. On the other hand, the relay peer generates send data unitsbased on the receive data units, and transmits these send data units tothe receiving peer. In accordance with the invention, the receive dataunits (i.e. the data units received from the sending peer) and the senddata units (i.e. the data units transmitted to the receiving peer) usethe same sequence position identifiers. When the relay peer receives afeed back message on the receiver-side (from the receiving peer 32_2 inthe example of FIG. 3), then it generates a sender-side feedback messagedirected towards the sender-side peer (the sending peer 30_2 in theexample of FIG. 3) carrying the second type of receipt information forthe given sequence position identifier that was already associated withthe second type of receipt information in the receiver-side feedbackmessage. Expressed in other words, when the relay peer receives anacknowledgement that a data unit has been correctly received at thefinal destination peer, then such an acknowledgement is passed ontowards the sender.

Based on the use of two different kinds of receipt information, one forindicating correct receipt at a relay device and another for indicatingcorrect receipt at the final destination, the sender and the relaydevice (or several relay devices, if more than one relay device isinvolved) can appropriately manage their own retransmission function andbuffer management, while both end-to-end-reliability and reliability onindividual hops is ensured. This is achieved without the necessity ofsub-layering, and consequently without the complexities or problems thatoccur due to ARQ conflicts between different sub-layers.

The present invention provides a highly reliable mechanism for multi-hopdata unit communication that is very simple at the same time.

BRIEF DESCRIPTION OF FIGURES

The present invention will be explained in more detail in the followingby making reference to specific embodiments that are described withrespect to the figures, where

FIG. 1 shows a basic protocol architecture of the known split connectionconcept;

FIG. 2 shows the basic protocol architecture of the known sub-layeringconcept;

FIG. 3 shows a link layer example of the basic protocol architecture ofthe present invention;

FIG. 4 schematically shows an example of a communication in accordancewith an embodiment of the present invention;

FIG. 5 schematically shows a specific data unit and message exchange inan embodiment of the present invention;

FIG. 6 shows a further example of an embodiment of the presentinvention;

FIG. 7 shows an embodiment of the present invention, in which two relaydevices operate in parallel;

FIG. 8 shows an embodiment of the present invention, in which two relaydevices are connected sequentially;

FIG. 9 is an explanatory, schematic diagram for explaining an embodimentof the invention, in which flow control is adjusted based on feedbackinformation;

FIG. 10 shows a schematic diagram of an embodiment of a data unitsender;

FIG. 11 shows a schematic diagram of a data unit relay device;

FIG. 12 shows a flowchart of an embodiment of a method for controlling adata unit sender;

FIG. 13 shows a flowchart of another embodiment of a method forcontrolling a data unit sender; and

FIG. 14 a-c show flowcharts describing parts of a method embodiment forcontrolling a data unit relay device.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 10 shows a schematic arrangement of a data unit sender 100 arrangedin accordance with an embodiment of the present invention. The data unitsender 100 comprises a data unit buffer 1002 for holding data units 1003of a communication protocol. A control unit 1001 is arranged to controla transmission of the data units 1003 to a peer of the communicationprotocol, a processing of feedback messages 1004 received from thatpeer, a re-transmission of the data units 1003 based on the feedbackmessages 1004, and a management of the buffer The control unit 1001 isarranged to let the data unit sender 100 act as a sending peer of thementioned communication protocol. The term “buffer management” means thecontrolled placing of data units into the buffer and the controlledremoval of data units from the buffer.

The buffer can be any type of memory suitable for holding data units,and the control unit can equally be any device suitable for performingthe control functions, e.g. the control unit can be a programmableprocessor.

The communication protocol is such that the data units 1003 are arrangedin a sequence, and each sent data unit is identifiable by a sequenceposition identifier. The feedback messages 1004 use the sequenceposition identifiers and carry information on the receipt of the dataunits 1003. In accordance with the invention, the communication protocolprovides for at least a first type and a second type of receiptinformation. The first type of receipt information is indicative of acorrect receipt of a data unit 1003 at a relay peer of the communicationprotocol, and the second type of receipt information is indicative of acorrect receipt at a final destination peer of the communicationprotocol.

The control unit 1001 is arranged to perform a first re-transmissioncontrol procedure for a given data unit that has been sent but for whichno first type receipt information has been received, and to perform asecond re-transmission control procedure for the given data unit if thefirst type receipt information has been received. Furthermore, thecontrol unit 1001 is arranged to hold the given data unit in the buffer1002 at least until having received the second type of receiptinformation for the given data unit.

In accordance with the present invention, the data unit sender iscapable of distinguishing whether a sent data unit of the givencommunication protocol was correctly received at a relay peer of thegiven communication protocol, or whether it was received at the finaldestination peer of the protocol. The sending peer can accordinglyadjust its re-transmission procedure. Namely, if no first type receiptinformation is received for a given data unit, this means that thesender has no acknowledgement that it was received at a relay peer. Inthis case the first re-transmission procedure is used, which is arrangedto ensure reliable delivery to the next peer, typically a relay peer. Onthe other hand, if the first receipt information has been received for agiven data unit, this means that delivery to a relay peer wassuccessful, and the second re-transmission control procedure can beused, which is different from the first in that the sender can at leasttemporarily delegate the responsibility for the further delivery of thedata unit to the relay device that sent the first type receiptinformation. Nonetheless, the second re-transmission control procedurehas a retransmission function, in order to be able to safeguard reliabletransmission to the final destination peer in the event that problemsoccur at the one or more relay peers involved in the communication. Asan example, the first re-transmission control procedure can be based ona time-out function having a first time-out value, such that if no firsttype receipt information is received within the time span of said firsttime-out value, a re-transmission is performed. The secondre-transmission control procedure can be based on a second time-outvalue, such that if no second type receipt information is receivedwithin the second time-out period, then a re-transmission is performed.The second time-out period is longer than the first time-out period.Another example is if the protocol additionally provides for third typereceipt information, which indicates an incorrect receipt (an incorrectreceipt means not received at all or received with an incorrectableerror), then the second re-transmission control procedure may be chosensuch that there is no time-out function, but that a data unit isre-transmitted in the event that the above-mentioned third type ofreceipt information is received, even if previously the first typereceipt information was received for the same data unit. Differentpossibilities for the first and second re-transmission controlprocedures will be explained in more detail with reference to FIGS. 12and 13 later.

It is noted that the sequence position identifiers, which are shown asn, n+1, n+2, . . . , m, m+1, . . . in FIG. 10 b, can be chosen in anysuitable or desirable way. Namely, they can be chosen as shown in theexample of FIG. 10, i.e. as integer values that directly correspond tothe sequence position (1, 2, 3, . . . ). However, they can e.g. also bechosen as bit or byte count values, which indicate a certain bit or byteposition in a data symbol stream that is being transported in the dataunits. Such a concept is e.g. known from TCP/IP.

In the example of FIG. 10, each data unit 1003 carries a sequenceposition identifier, and the shown feedback message 1004 also each carrya sequence position identifier. In the shown example, the first feedbackmessage 1004 carries an “A”, which stands for ACK, which in turn will beused in the present specification as an example for the second typereceipt information. The second feedback message 1004 contains an R,which stands for RACK, which will be used in the present specificationas an example of the first type receipt information. RACK stands forrelay acknowledgement.

Naturally, this is only one possibility of many for associating thesequence position identifiers with the data units and feedback messages.For example, it is possible to place several data units into onemessage, where the message e.g. only contains the first sequenceposition identifier, and a peer receiving said message can then identifythe sequence position identifier for each data unit by using the firstsequence position identifier and counting the number of data units inthe message. Equally, the feedback messages can relate to a plurality ofdata units, where it can again be sufficient to only indicate the firstand/or last sequence position identifier for a sub-sequence of dataunits to which the feedback message relates.

Now two examples of control methods for controlling the data unit sender100 shown in FIG. 10 will be described with reference to FIGS. 12 and13.

FIG. 12 shows a flowchart of a first example of a control method for thedata unit sender 100, e.g. implemented in the form of software incontrol unit 1001. In a first step S121 a given data unit is generatedand stored in a buffer 1002. In subsequent step S122 this data unit istransmitted. A specific procedure according to which individual dataunits are released from the buffer 1002, i.e. the specifics of flowcontrol, can be chosen in any suitable or desirable way. For example,the flow control can be window-based or rate-based. The presentinvention is independent of the type of flow control used.

In step S123 a re-transmission timer is started to a first time-outperiod TO_1. Then step S124 determines whether an ACK (second type ofreceipt information) or a RACK (first type of receipt information) hasbeen received for a sent data unit. If not, step S125 determines whetherTO_1 has expired yet. If not, the procedure loops back to step S124, andif the period TO_1 has expired, then the procedure goes to step S126, inwhich the given data unit is re-transmitted. After step S126, theprocedure loops back to step S123.

Steps S123-S126 constitute an example of a first re-transmission controlprocedure for the given data unit in buffer 1002 that has been sent butfor which no RACK has been received.

If step S124 determines that an ACK or RACK has been received for thegiven data unit, the procedure goes to step S127, in which it isdetermined whether the received feedback was a RACK. If yes, then are-transmission timer is started with a second time-out period valueTO_2. Then step S129 determines whether subsequently an ACK has beenreceived for the given data unit, i.e. the second type receiptinformation which indicates that the given data unit was received at thefinal destination peer. If not, then step S130 determines whether TO_2has expired, and if not the procedure loops back to step S129. If TO_2has expired, the procedure goes to step S132, in which the given dataunit is re-transmitted. The procedure then loops back to step S123, i.e.treats the re-transmitted data unit as a data unit for which no RACK hasyet been received. Steps S128, S129, S130 and S132 constitute an exampleof a second re-transmission control procedure for a given data unit iffirst type receipt information (RACK) has been received for the givendata unit.

Finally, if the outcome of step S127 indicates that an ACK has beenreceived in step S124, or if an ACK was received in step S129, then theprocedure goes to step S131, in which the given data unit for which theACK was received is removed from buffer 1002. It is noted that this isonly an example, and the overall control procedure can comprise furthermechanisms that let a given data unit be held even after an ACK wasreceived. Such mechanisms are outside of the scope of the presentinvention and shall not be discussed further here. However, inaccordance with the present invention, a given data unit is held in thebuffer at least until the ACK (second type of receipt information) thatacknowledges receipt at the final destination peer has been received. Inthis way, despite being able to delegate responsibility to one or morerelay peers, the sending peer keeps final control over the end-to-enddelivery to the final destination, because data units in the sendingpeer are not removed until receipt at the final destination has beenconfirmed. Due to this, the sending peer can always take backresponsibility for delivery of data units, such that problems at one ormore relay peers do not lead to an irrevocable loss of data units at thelevel of the communication protocol being described.

In the example of FIG. 12, the first time-out period TO_1 is shorterthan the second time-out period TO_2. This is due to the considerationthat the first timeout period TO_1 serves to appropriately re-transmitdata units on the first hop from the sending peer to the immediatelyadjacent relay peer. On the other hand, the second time-out period TO_2serves to enable re-transmission if an end-to-end problem occurs, e.g.in one or more of the relay peers. As the expected end-to-end deliverytime is longer than the expected delivery time on the first hop, thesecond time-out period TO_2 is chosen larger than the first time-outperiod TO_1.

However, it is also possible to select TO_1 and TO_2 as equal. Forexample, in situations in which a relay peer sends feedback messages atregular time intervals, TO_1 and TO_2 can be set to the same value.

Optionally, the control unit 1001 and the corresponding control methodare arranged such that the first time-out period TO_1 is adapteddynamically based on measurements of a time that passes between atransmission of at least some of the data units 1003 and the receipt ofa RACK, and the second time-out period TO_2 is dynamically adapted basedon a measurement of a time that passes between a transmission of atleast some of the data units 1003 and a receipt of an ACK. For example,the data unit sender can keep an average value of the time betweensending a data unit and receiving a corresponding RACK, and an averageof the time that passes between the sending of a data unit and thereceipt of an ACK, and then dynamically adjust TO_1 on the basis of theaverage value for receiving a RACK, and TO_2 on the basis of the averagevalue for receiving an ACK. Any known technique for measuring round triptimes (RTT) can be used for such measurements.

FIG. 13 is a flowchart of another embodiment of a control method forcontrolling the data unit sender 100. In the example of FIG. 13, thecommunication protocol governing the communication provides for a thirdtype of receipt information that is indicative of an incorrect receiptof a data unit at a peer of the communication protocol. This third typeof receipt information will also be referred to as a NACK or negativeacknowledgement. An incorrect receipt means that a data unit is notreceived at all or received with incorrectable errors.

In FIG. 13, the method is the same as that of FIG. 12 with respect tosteps S121 to S125, such that a repeated description is not necessary.However, if the outcome of step S125 is negative, i.e. TO_1 has notexpired, then the procedure goes to an additional step S133, in which itis determined whether a NACK has been received for the given data unit.If this is the case, the procedure goes to step S126, to re-transmit thegiven data unit. If no NACK has been received, the procedure loops backto step S124. Steps S123-126 and S133 constitute another example of afirst re-transmission control procedure for a given data unit that hasbeen sent but for which no RACK has been received.

If the outcome of step S124 in FIG. 13 indicates that an ACK or RACK hasbeen received, then the procedure goes to step S127, in which it isdetermined whether a RACK has been received, just like in the method ofFIG. 12. If a RACK has been received, then the procedure directly passesto step S129, in order to determine whether a subsequent ACK has beenreceived or not. If not, then it is asked whether a subsequent NACK hasbeen received for the given data unit, see step S134. If no NACK hasbeen received, the procedure loops back to step S129. If a NACK has beenreceived, then the given data unit is re-transmitted in step S132, whereafter the procedure loops back to step S123, similar to the procedure inthe example of FIG. 12. Steps S129, S134 and S132 constitute anotherexample of a second re-transmission control procedure for a given dataunit for which the first type receipt information (RACK) has beenreceived.

Finally, just as in the example of FIG. 12, if the outcomes of stepsS127 and S129 indicate that an ACK has been received, then thecorresponding data unit may be removed from the buffer in step S131.

In FIG. 13, steps S126 and S132 indicate the optional use of aretransmission prohibit timer. A retransmission prohibit timer can betriggered by a selected event, such as the transmission of a data unitand/or the retransmission of a data unit. Within the retransmissionprohibit time period, a retransmission is prohibited. If the peers ofthe present invention are operated such that feedback messages are sentat regular intervals, then it is preferable to employ a retransmissionprohibit timer, in order to avoid unnecessary retransmissions, e.g. toavoid unnecessary retransmissions each time that a NACK is received.When combining a retransmission prohibit timer feature with aretransmission time-out feature, the retransmission time-out period(such as TO_1 or TO_2) is set longer than the retransmission prohibitperiod. In other words, steps S126 and S132 can be implemented in such away that a retransmission is in any case conducted if the procedureprogresses to these steps, or a retransmission is only conducted if theretransmission prohibit time period has additionally expired. If thesteps S126 or S132 are reached because of a time-out of a retransmissiontime-out period, then the retransmission prohibit time period will haveexpired, but if these steps are reached on account of a NACK, then theretransmission prohibit time period may not yet have expired.

The effects of the example of FIG. 13 are the same as in FIG. 12.Namely, a first and a second re-transmission control procedure for adata unit are provided, the first dealing with reliable delivery of thefirst hop to a relay peer, and the second dealing with end-to-enddelivery, where the triggering of the respective differentre-transmission control procedures is based upon having received thefirst type receipt information (RACK) for a given data unit or not.Also, the given data unit is held in the buffer at least until thesecond type receipt information (ACK) has been received. Thereby, thedata unit sender is capable of always taking back responsibility for adelivery of a data unit, even if this responsibility had previously beentemporarily passed to a relay peer.

It is noted that in the above discussion it was generally assumed thatthe adjacent peer to the sending peer is a relay peer. However, it isimportant to note that the next peer can also already be the finaldestination peer. In this case, the data unit sender and correspondingcontrol method of the present invention will automatically fall backinto a standard ARQ procedure, because the final destination peer willdirectly send ACKs to the sending peer. Such operation requiresabsolutely no adjustment in the sending peer of the invention. This isan important advantage of the invention.

Regarding the examples of FIGS. 12 and 13, it is noted that variationsare naturally possible. For example, it is also possible to combine thefeature of the second time-out period TO_2 (as shown in FIG. 12) withthe concept of re-transmission upon receiving a NACK (step S134 in FIG.13).

Now a schematic representation of an embodiment of a data unit relaydevice of the invention will be described with reference to FIG. 11.

The data unit relay device 110 comprises a data unit buffer 1102 forholding receive data units 1102 of a communication protocol receivedfrom a sender-side peer of that protocol, and for holding send dataunits 1103 of the communication protocol to be sent to a receiver-sidepeer. The sender-side peer can be an original sending peer (as e.g.described in FIG. 10) or another relay device placed between theoriginal sender and the relay device 110 of FIG. 11. Equally, thereceiver-side peer can be the final destination peer, or another relaypeer provided between data unit relay device 110 and the finaldestination peer.

Data relay device 110 has a control unit 1101, which is arranged tocontrol a receiving of the receive data units 1102, a transmission ofthe send data units 1103, a processing of receiver-side feedbackmessages 1104 received from the receiver-side peer, a re-transmission ofthe send data units 1103 to the receiver-side peer based on thereceiver-side feedback messages 1104, a transmission of sender-sidefeedback messages 1105 to the sender-side peer, and the overallmanagement of the buffer, as a relay peer of the given communicationprotocol. The “management of the buffer” means the placing of data unitsin the buffer and the removing of data units from the buffer.

The buffer can be any type of memory suitable for holding data units,and the control unit can equally be any device suitable for performingthe control functions, e.g. the control unit can be a programmableprocessor.

As already described in connection with the sender in FIG. 10, thecommunication protocol is such that the receive data units 1102 arearranged in a sequence, and each receive data unit 1102 is identified bya sequence position identifier, indicated as n, n+1, n+2 in FIG. 11. Thesend data units 1103 are arranged in the same sequence, such that foreach receive data unit 1102 there is a corresponding send data unit 1103having at least a same payload section and the same sequence positionidentifier. Preferably, the receive data units and send data units notonly have the same payload section and the same sequence positionidentifier, but are in fact identical. This simplifies buffermanagement, as the buffer 1102 then only holds the received data unitsand appropriately forwards them, without the action of copying parts ofdata units, which may lead to errors.

The sender-side feedback messages 1105 and the receiver-side feedbackmessages 1104 use the sequence position identifier and carry informationas already described in connection with the sender of FIG. 10. Namely,the communication protocol provides for at least a first type and secondtype of receipt information, where the first type (RACK) is indicativeof a correct receipt at a data unit relay device, and the second type isindicative of a correct receipt at the final destination peer.

The control unit 1101 is arranged to send a sender-side feedback messagecarrying the first type of receipt information (RACK) for a givenreceive data unit 1102 that was correctly received. This is e.g. shownby the sender-side feedback message 1105 carrying an R for sequenceposition identifier n+2.

The control unit 1101 is furthermore arranged to perform are-transmission control process for a given send data unit 1103 in thebuffer 1102 that has been sent, based on the receiver-side feedbackmessages 1104.

The control unit 1101 is furthermore arranged to hold a given send dataunit 1103 in the buffer 1102 until a predetermined deletion condition isfulfilled. One such possible deletion condition is the receipt of areceiver-side feedback message 1104 providing the second type of receiptinformation (ACK) for the given data unit.

The control unit 1101 is furthermore arranged such that after havingreceived the second type of receipt information (ACK) for a givensequence position identifier in a receiver-side feedback message 1104, acorresponding sender-side feedback message 1105 is sent to thesender-side peer, carrying the second type of receipt information (ACK)for the given sequence position identifier. This is shown in FIG. 11 interms of the receiver-side feedback message 1104 carrying an A (for ACK)for sequence position identifier m, such that the data unit relay device110 then sends the sender-side feedback message 1105 that equallycarries an A (for ACK) for said sequence position identifier m.

Examples of parts of the control method for controlling the data unitrelay device 110, e.g. executed as software in control unit 1101, willnow be explained with reference to FIGS. 14 a-14 c.

FIG. 14 a shows a procedure, where if a sender-side data unit 1102 iscorrectly received, step S140 branches to step S141, in which acorresponding RACK is sent for the given data unit, i.e. for thesequence position identifier of said data unit.

FIG. 14 b shows a flowchart of a process for generating a sender-sidefeedback message with an ACK, if a receiver-side feedback with an ACK isreceived. Namely, step S142 determines whether a receiver-side feedbackmessage with an ACK for a particular sequence position identifier hasbeen received, and if this is the case, step S143 sends a sender-sidefeedback message with an ACK for the same sequence position identifier.

FIG. 14 c shows an example of a procedure for performing are-transmission control process for transmitted send data units. In afirst step S144, a send data unit 1103 is transmitted. Thereafter, instep S145, a re-transmission timer is set to a time-out period TO_1. Theprocedure then determines whether an ACK (second type receiptinformation) has been received, see step S146. If not, it is determinedin step S147 whether TO_1 has expired. If not, the procedure loops backto step S146. If yes, then a re-transmission of the given send data unitis performed in step S148, and the procedure loops back to step S145. Ifstep S146 indicates that an ACK has been received, then the send dataunit for which the ACK has been received is removed from the buffer 1102in step S149. Receiving an ACK is an example of a deletion condition fora data unit. However, other deletion conditions can also be chosen. Forexample, it is also possible that, upon placing a given data unit intothe buffer 1102, a purge timer is set to a predetermined purge timeperiod, and if said purge time period expires, the corresponding dataunit is simply removed from the buffer. This has the purpose of avoidingthe indefinite buffering of data units for which no second type receiptinformation has been received. Another deletion condition is thereceiving of an indication that the sending peer has actually receivedthe feedback message that forwards the ACK.

Furthermore, it is noted that FIG. 14 c is an example of are-transmission control process that does not involve RACKs. Namely, there-transmission procedure for send data units 1103 can be chosen in anyway suitable for the given situation. If the data unit relay device 110is arranged such that the send data units 1103 are directly sent to thefinal destination peer, then the re-transmission control procedure onlyneeds to take ACKs into account.

On the other hand, in the more general case that the data unit relaydevice 110 transmits send data units 1103 to another data unit relaydevice, then it is preferable that the re-transmission control processexecuted at the data unit relay device 110 of FIG. 11 also processes thefirst type receipt information, i.e. RACKs. The basic arrangement of thecontrol unit 1101 with respect to send data units 1103 can then be thesame as that of control unit 1101 of sender 100 with respect to the dataunits 1003 sent by data unit sender 100. As a consequence, the controlunit 1101 of data unit relay device 110 can e.g. implement the controlprocedures described in FIGS. 12 and 13 with respect to the send dataunits 1103. A renewed description of these procedures is therefore notnecessary.

If the underlying communication protocol provides for the abovedescribed third type of receipt information, i.e. a NACK that isindicative of an incorrect receipt of a data unit at a peer of thecommunication protocol, then the control unit 1101 of data unit relaydevice 110 is preferably arranged in such a way that if a receiver-sidefeedback message 1104 is received that carries this third type ofreceipt information for a sequence position identifier for which no dataunit 1103 or 1102 is stored in said buffer, a sender-side feedbackmessage 1105 is sent that carries this third type of receipt informationfor that sequence position identifier. In other words, the data unitrelay device and the corresponding control method are arranged such thatif a NACK is received for a data unit that is not present in the relaydevices buffer, then this NACK is forwarded to the next peer in theoverall direction of the end-to-end sender. Furthermore, the data unitrelay device and corresponding control method are also preferably suchthat if in response to such a forwarded NACK, a correspondingsender-side data unit 1102 is received (i.e. the previous peer hasretransmitted the NACKed data unit), then the send control on thereceiver-side should be such that a corresponding send data unit 1103 istransmitted.

When using the above-mentioned feature of forwarding NACKs, thefollowing benefit can be achieved. If for whatever reason a data unitrelay device does not have certain data units in its buffer (one reasoncould be that the data unit relay device has just been introduced intothe communication by a handover process and is therefore just beginningto receive sender-side data units 1102, but is nonetheless also alreadyreceiving receiver-side feedback messages 1104), then the overall ARQmechanism still functions without any problems. Namely, if the data unitrelay device does not have a particular data unit present for which aNACK has arrived, such that it cannot itself perform a re-transmissionfor this data unit, it simply forwards the NACK towards the nextpossible sender. If no data unit relay device along a given path iscapable of re-transmission, because the data unit is lacking in eachrespective buffer, then the NACK will finally arrive at the originalsending peer. If the original sending peer has not yet received an ACKfor that data unit, then it can simply be re-transmitted. This is anexample of the sending peer taking back the responsibility for reliabletransmission if problems occur in one or more data unit relay devices.Naturally, if the sending peer has previously received an ACK for thegiven data unit, then the forwarded NACK can simply be ignored.

Regarding the processing of RACKs received in receiver-side feedbackmessages, the data unit relay device can be arranged in any suitable ordesirable way. For example, it is possible that received RACKs are neverforwarded, in order to avoid unnecessary data traffic. On the otherhand, it is equally well possible to always forward RACK informationtowards the sender-side. This can e.g. be useful to provide the sendingpeer with more information on the progress in moving a data unit over aseries of relay peers (each RACK message is an indication that the dataunit has moved one hop forward), or it can also be useful if thefeedback messages are collective feedback messages that relate to aplurality of data units. In this case, the feedback messages constitutea type of status report on a number of data units, and for each dataunit identified the feedback messages preferably indicate one of thefirst to third receipt information, i.e. either a RACK, an ACK or aNACK. Such collective feedback messages will be discussed in more detailfurther on.

It is also possible to perform a forwarding of RACKs in such a way thatif a receiver-side feedback message carrying a RACK for a given sequenceposition identifier is received, a corresponding sender-side feedbackmessage with a RACK for said given sequence position identifier is onlythen sent, if there is no corresponding data unit having said givensequence position identifier stored in the buffer 1102. The usefulnessof this feature lies in the fact that if a given data unit is present inthe buffer 1102 of the data unit relay device 110, then this means thata RACK for said data unit has already been sent previously. A repeatedRACK is avoided. However, if there is no corresponding data unit in thebuffer 1102 of data unit relay device 110, then it is possible that thesource of the data unit has not yet been informed of the correct receiptat a relay peer such that the forwarding of the RACK is useful.

Now a plurality of examples will be described in somewhat more detail.

FIG. 4 shows a system comprising a sender 40, a relay 41 and a receiver42. Each of the devices implements a peer of the inventive communicationprotocol. The sender 40 is an example of the data unit sender describedin connection with FIG. 10, and relay 41 is an example of the data unitrelay device 110 described in connection with FIG. 11. On the left-handside of FIG. 4, the sequence of data units 44 is shown, each representedtogether with an integer that stands for the sequence positionidentifier. The arrows at the top of FIG. 4 indicate the flow of dataunits from the sender to the relay and from the relay to the receiver,without providing further detail.

The sender 40, relay 41 and receiver 42 each keep a respectivetransmission and/or reception status with respect to the sequence ofdata units 44. The receiver 42 sends feedback messages 45 to the relay41, and the relay 41 sends feedback messages 46 to the sender 40. Thesefeedback messages 45, 46 are collective status reports for a group ofdata units. For example, feedback message 45 associates data unit 1 withan ACK, data unit 2 with a NACK, and data units 3 and 4 with an ACK,respectively. This corresponds to the receiver status of receiver 42,namely where “ok” indicates correct receipt, and “err” indicatesincorrect receipt.

Based on status message 45, the relay device 41 keeps a correspondingtransmission status, i.e. the status on the successful or unsuccessfultransmission of send data units (see 1103 in FIG. 11). The symbol “ns”stands for not sent. Relay device 41 furthermore keeps a receiverstatus, in which data units 1-4 are correctly received (“ok”), just likedata units 6 and 7, whereas data unit 5 was not correctly received.Accordingly, the feedback message 46 contains ACKs for data units 1, 3and 4, because these were already successfully acknowledged by thereceiver 42. In other words, the sender-side feedback message 46forwards the acknowledgements for data units with sequence positionidentifiers 1, 3 and 4. On the other hand, the feedback message 46contains RACKs for data units 2, 6 and 7, because these data units weresuccessfully received by the relay 41, but not acknowledged by thereceiver 42, i.e. the final destination peer. Finally, the feedbackmessage 46 carries a NACK for data unit no. 5, because this data unitwas not successfully received at the relay 41.

The sender 40 maintains a transmission status that is based upon theinformation received in the feedback message 46. Namely, data units forwhich an ACK was received or marked as “ok”, those for which a RACK wasreceived are marked as “rok”, and those for which a NACK was received orfor which no feedback was received within the corresponding time-outperiod are marked as “err”. In the example of FIG. 4, the sender 40could at the shown state of transmission remove data units no. 1, 3 and4, as these are known to have been successfully received at the finaldestination peer in receiver 42.

The first, second and third type receipt information can be coded in anysuitable or desirable way. For example, two bits are sufficient to codethe three different types. The feedback messages can therefore combinean appropriate receipt type bit value with the sequence positionidentifier for a given data unit. The coding used by the sender, relayand receiver for keeping a transmission and/or receive status canequally be chosen in any suitable or desirable way. For example, thefour states ok, rok, err and ns can be coded by two bits.

In the example of FIG. 4, the relay peer in device 41 is operated suchthat if a receiver-side feedback message with a NACK is received, andthe corresponding data unit has a receive status at 41 of err, then theNACK is forwarded to the sending peer in sender 40, and as soon as thedata unit retransmitted by the sending peer has been received locally atdevice 41, it is transmitted to the peer in receiver 42. If areceiver-side feedback message with a NACK is received, and thecorresponding data unit has a receive status at 41 of ok, then the relaypeer in device 41 performs the corresponding retransmission. If areceiver-side feedback message with a RACK is received, and thecorresponding data unit has a receive status at 41 of ok, then the relaypeer in device 41 forwards the RACK to the sending peer in 40 in thenext status report. Finally, if a receiver-side feedback message with anACK is received, then the relay peer in device 41 forwards the ACK tothe receiving peer in the next status report.

The relay device 41 can perform in-order delivery with respect to thesequence of data unit 44, or out-of-order delivery. Preferably, therelay device performs out-of-order delivery, i.e. relays receiver-sidedata units 1103 (see FIG. 11) as they are available, irrespective of theorder of the sequence. Correspondingly, the receiver 42 preferably has are-sequencing functionality.

FIG. 5 shows an example of a data unit transmission at the link layerbetween a user terminal UT and a network access point AP, via a relaynode RN. At 51) the UT sends one data unit to the RN and starts atime-out timer. At 52) the data unit is lost on its way to the RN. At53) no RACK or ACK arrives at the ARQ transmitter in time, such that thetimer times-out and the data unit is re-transmitted. At 54) the dataunit arrives at the RN and triggers the sending of a RACK. At 55 thedata unit is delivered to the AP and another timer is started locally inthe RN, in order to provide a re-transmission over the link from RN toAP in case of a data unit loss there. At 56) the UT receives the RACKand therefore knows that the responsibility for further delivery of thedata unit is at least temporarily delegated to the RN. At 57) the APsuccessfully receives the data unit and replies with an ACK, i.e. thesecond type of receive information. At 58) the ACK received at RN isforwarded to the UT. At 59) the UT receives the ACK and consequently isinformed that the data unit has been correctly delivered to thedestination point. 60) indicates an option according to which the UT(generally the sending peer) sends an indication to RN (in general thenext peer in direction of the receiver) that the ACK has successfullyreached the sender. This is sometimes also called an ACK-ACK.

The usefulness of such ACK-ACKs is to let the data unit relay devicefinally release data units from its buffer. Therefore the receipt ofsuch an ACK-ACK from the sender-side is another example of a deletioncondition as explained in connection with FIG. 11. Preferably, eachrelay device is arranged to forward such an ACK-ACK in receiverdirection, i.e. to the next receiver-side peer. In this way each peer ofa chain is informed of the fact that the sending peer has been informedof the successful end-to-end transmission, such that the correspondingdata unit can now certainly be removed from the respective local buffer.

FIG. 6 shows another example, in which four data units carryingidentifiers 1, 2, 3 and 4 are sent from a sender 61 to a receiver 63 viaa relay 62. The relay node 62 in-between forwards the data units as soonas it receives them, i.e. performs out-of-order delivery. Both the relay62 and the receiver 63 send feedback messages to the respective peer insender direction, to inform the peer about successfully orunsuccessfully received data units.

In this example, a status message is sent whenever the respective peerreceives a correct data unit. Although this is a preferable embodiment,it is by no means a necessity. For example, feedback messages can besent at regular intervals or at both regular intervals and whenever acorrect data unit is received.

In the example of FIG. 6, the first re-transmission control procedure(re-transmission control procedure for a given data unit that has beensent but for which no RACK has been received) and the re-transmissioncontrol process at the relay use a time-out value in the order of oneround trip time RTT for the respective hop from sender 61 to relay 62,or relay 62 to receiver 63.

In the shown example, sender 61 sends data units 1, 2, 3, 4 one afterthe other. Data units 2 and 3 are lost on their way to relay 62. Whenrelay 62 receives data unit no. 1, it sends a RACK to sender 61 andforwards data unit 1 to receiver 63. When data unit 1 arrives atreceiver 63, an ACK (see message (A1)) is sent by receiver 63 to relay62. In the example of FIG. 6, relay 62 does not immediately forward theACK for data unit no. 1, but much rather waits until another data unitarrives from the sender, to then send a collective feedback message.Naturally, the data unit relay device of the present invention couldalso be implemented in such a way that receiver-side acknowledgementsare immediately forwarded to the sender-side.

In the example of FIG. 6 the numbers attached to arrows simply identifya corresponding data unit. These numbers are sequence numbers, i.e. anexample of a sequence position identifier. The indications inparentheses attached to feedback messages are to be read in thefollowing way: an A followed by a number indicates an ACK for the dataunit of said number, an N followed by a number indicates a NACK for saidnumber and an R followed by a number is a RACK for said number. Thetransmission status confirmation written on the left-hand side forsender 61 is such that R followed by a number indicates a rok for thedata unit of said number, N followed by a number indicates an err forthe data unit of said number (i.e. that a NACK was received for saiddata unit or no feedback was received within the applicable time-outperiod), and A followed by a number indicates an ok for the data unit ofthat number. The same nomenclature will be used in the examples of FIGS.7 and 8 as well.

Returning to the example of FIG. 6, the sender 61 updates itstransmission status at first to (R1), due to receiving a RACK for dataunit number 1. Thereafter, due to not receiving any feedback for sentdata units 2 and 3, the status is updated to err for data units number 2and 3. Due to the time-out, data units 2 and 3 are retransmitted bysender 61. Relay 62 receives data units 2 and 3, and forwards them. Inthe example of FIG. 6, data unit 2 is lost on the hop from relay 62 toreceiver 63, but data unit 3 is correctly delivered. Accordingly, thereceiver acknowledges the receipt of data unit number 3 (see feedbackmessage (A1, N2, A3, A4)). Relay 62 retransmits data unit number 2 dueto a time-out. After data unit 2 is correctly received at receiver 63,an appropriate feedback message is sent that finally acknowledges allfour data units. It can also be seen in the example of FIG. 6 how therelay 62 appropriately forwards the ACKs from receiver 63 to sender 61,and sends RACKs for the data units that it locally receives.

In accordance with the present invention, a system and method areprovided for a reliable transport for data units over a multi-hopconnection, which system and method are very simple, but at the sametime provide full reliability. These are not the only advantages of thepresent invention.

In accordance with the present invention, it is very simple to perform atransition from one relay device to another, e.g. in a handover. Due tothe fact that the sending peer retains the overall responsibility forend-to-end delivery, it is not necessary that the old relay deviceperforms a transfer of state information to the new relay device. Inother words, data units that were already received by the old relay butnot yet successfully forwarded to the receiving peer can be assumed tobe lost, without this affecting the end-to-end reliability. Namely, thesending peer of the invention can take back the responsibility for thesedata units and ensure end-to-end delivery.

The process of switching from one relay device to another can be done inany suitable or desirable way, and can e.g. be performed in accordancewith any known handover procedure such that a further description is notnecessary here.

As soon as the new relay device receives the first data units from thesender-side, it can begin to build up an appropriate receive state, andequally when it begins to receive feedback messages from thereceiver-side, it can accordingly begin to build up a transmissionstate. Furthermore, the relay device generates its own feedback messagesto be sent towards the sender-side, to report on the state of thereceiver-side of the relay device (namely by appropriately forwardingACKs and/or NACKs), and on its own receive status.

By appropriately forwarding receiver-side feedback information to thesender-side, for data units that the new relay device itself has neverreceived, the peer(s) on the relay device's sender-side (e.g. in thesimple two-hop case of sending peer, one relay peer and receiving peer,there is only one sender-side peer for the relay, namely the sendingpeer itself) are appropriately informed of the correct receipt of dataunits at the receiver, namely through forwarded ACKS, or of data unitsnot having been correctly received, namely by NACKs. In the event offorwarding a NACK, the new relay device expects to receive aretransmission for the corresponding data unit, and will forward thethus transmitted data unit once is arrives. On the other hand, if thenew relay device forwards an ACK, it does not expect to receive anyfurther communications with respect to that data unit, except possiblyfor ACK-ACKs as described in connection with the example of FIG. 5. Asdiscussed in connection with FIG. 5, the use of ACK-ACKs is an option.

As a result, the concept of the present invention can ensure a seamlesstransition from an old relay device to a new relay device withoutrequiring any complicated transfers of state information between the oldrelay and the new relay. Much rather, the use of first type and secondtype receipt information, and preferably also third type receiptinformation as described above, together with the appropriate relayingof this receipt information in feedback messages, provides for reliabletransmission.

Effectively, each peer that transmits data units can delegate theresponsibility for retransmissions to the next peer in the chain fromsender to receiver as soon as this next peer has sent a RACK for a givendata unit. If the next peer becomes obsolete for any reason, the peercan take back the responsibility. The ultimate responsibility can betaken back by the sending peer, i.e. the first peer in the chain.

Preferably, each peer that transmits data units (i.e. the sending peer,and each relay peer) implements a mechanism to check whether the nextpeer in the chain is still valid or acting. This can be done in anysuitable or desirable way. For example, peers connected over one hop canexchange polling messages on an event basis or in predetermined timeintervals. Or each peer that receives data units can regularly sendalive signals to the preceding peer in the chain. As anotherpossibility, each peer that transmits data units can treat a hop to anext peer as dead if no feedback at all is received within a given timeperiod, e.g. a predetermined number of retransmission time-out periodsfor the given hop. Upon determining that the hop to the next peer isdead, the peer in question can initiate a procedure for switching to anew next peer, or can alternatively inform a preceding peer in the chainthat it should switch to a new next peer.

As can be seen from the above explanation, the concept of the presentinvention allows the simple replacement of one relay device by another.Equally, the present invention allows the adding or removing of a relaydevice to an ongoing end-to-end communication. In other words, ifnecessary, a two-hop connection as shown in FIGS. 4-6 can be augmentedto three-hop connection, or a k-hop (k is an integer greater than 1) cansimply be switched to a (k−1) hop connection. The addition or removal ofa relay device is very similar to the above-described change from an oldrelay device to a new relay device.

When adding a new relay device, the added relay device starts to buildup a receive state and a transmission state exactly in the same way asthe above-described new relay device does this after a handover.Consequently, a repeated description is not necessary.

In accordance with an embodiment of the invention, in a data unit relaydevice that is arranged to operate in an environment in which relaydevices can be exchanged, added and/or dropped from an ongoingend-to-end peer connection, the following relay actions for feedbackinformation can be provided. If the relay peer in the relay devicereceives a receiver-side feedback message with a NACK, and thecorresponding data unit has a receipt status of err, then the NACK isforwarded to the next peer on the sender-side, and as soon as the dataunit in question is received, it is transmitted to the next peer on thereceiver-side. If a receiver-side feedback message with a NACK isreceived, and the corresponding data unit has a receive status of ok,then the relay peer performs the appropriate retransmission. If areceiver-side feedback message with a RACK is received, and thecorresponding data unit has a receive status of ok, then the relay peerforwards the RACK to the next peer on the sender-side in the nextfeedback message. If a receiver-side feedback message with a RACK isreceived, and the corresponding data unit has a receive status of err(i.e. the data unit has never been received at said relay device) thenthe relay peer forwards the RACK to the next peer on the sender-side inthe next feedback message. Due to having forwarded a RACK, the relaypeer does not wait or expect to receive the corresponding data unit infuture. If a receiver-side feedback message with an ACK is received,then the relay peer forwards the ACK to the next peer on the sender-sidein the next feedback message, and can possibly remove the correspondingdata unit from its buffer, if the relay peer has the receipt of an ACKas a deletion condition. It is noted that the forwarding of an ACK isnaturally also done if the corresponding data unit is not present in thebuffer of the relay device.

FIG. 8 shows an example of a data unit transmission from a sender 81 viatwo relay devices 82, 83 to a receiver 84. The nomenclature is the sameas used in FIG. 6. In this serial three-hop example, the sender 81 sendsfour data units being identified by their sequence position identifiers1, 2, 3 and 4 to the first relay 82. Data units 2 and 3 are lost on theway. As can be seen, the first relay device 82 sends RACKs for thereceived data units 1 and 4. On the other hand, the sender 81 considersdata units 2 and 3 as lost, due to a time-out of a first time-out periodTO 1 set in the order of the roundtrip time for the peer-to-peerconnection between sender 81 and the first relay 82. Consequently, thesender 81 retransmits data units 2 and 3. In response to theseretransmissions, the first relay device 82 sends RACK feedback messages.

As can furthermore be seen, the first relay 82 forwards each receiveddata unit upon arrival. As can be seen, data unit 2 is lost on its wayfrom the first relay 82 to the second relay 83. The first relay performsa retransmission on account of a time-out. Otherwise, the second relay83 sends RACK feedback messages for each correctly received data unit.The second relay 83 forwards the received data units to the receiver 84.As can be seen in the example, data unit 3 is lost on its way from thesecond relay 83 to receiver 84, and the second relay 83 accordinglyperforms a retransmission on account of a time-out. In the example ofFIG. 8, it is furthermore shown that the ACK sent by receiver 84 to thesecond relay 82 is lost. As a consequence, the second relay device 83also performs a retransmission of data unit number 4 on account of atime-out.

As can also be seen in the example of FIG. 8, feedback messages to thenext peer on the sender-side are only sent if appropriate. For example,the first relay 82 does not instantly report the successful delivery ofdata units to the second relay 83, i.e. the receipt of RACKs. Thesending of a feedback message is only triggered in the event of havingcorrectly received a data unit from the adjacent sender-side peer, inwhich case a RACK is sent, or when forwarding an ACK received from thereceiver-side. However, as already mentioned previously, this is onlyoption, and it would equally be possible to immediately forward all RACKmessages coming from the receiver-side, to thereby inform the adjacentpeer on the sender-side, and ultimately the sender, on the progress ofdata units from one hop to the next.

The case of removing a relay device from an ongoing end-to-endconnection can also be described by looking at the example of FIG. 8. Ifone assumes that the second relay device 83 is removed, then the firstrelay device 82 would take over the responsibility. Namely, it wouldbegin to directly send data units to the receiver 84, and to receivefeedback messages directly from the receiver 814. If for example theremoving of the second relay device 83 would have led to the loss ofdata units for which the second relay 83 had previously sent RACKmessages to the first relay 82, but which had not yet been correctlyforwarded to receiver 84, then receiver 84 would eventually send NACKmessages to the first relay 82, on the basis of which a retransmissioncould be performed by the first relay 82, despite the fact that thefirst relay 82 had previously received a RACK for the same data unit.

Now an example of the present invention will be described in connectionwith FIG. 7, in which two hops are operated in parallel. In the example,a sender 71 can in parallel send data units to a relay device 72 and arelay device 73. Both relays 72 and 73 communicate with a receiver 74.Such a parallel-hop situation can occur during a handover (i.e.simultaneous communication with an old relay device and a new relaydevice), or when different access techniques can be used at the sametime, i.e. one hop is provided by a WLAN connection and the other bydifferent wireless access technique, e.g. a UMTS connection.

In the example of FIG. 7, different delays on the hops are taken intoaccount. For simplicity, as in the examples of FIGS. 6 and 8, the delaysare assumed as being constant over time.

In the examples of FIGS. 6 and 8, only one data unit was sent at a time,or more precisely during one transmission time interval (TTI). Theinvention is by no means restricted thereto, and can also be applied ifseveral data units are sent per TTI, where FIG. 7 gives an example.

Both data unit relay devices 72 and 73 send their feedback messages backto the sender 71. The receiver 74 sends feedback messages to both thedata unit relay device 72 and the data unit relay device 73.

In FIG. 7, the data units 1, 2 and 3 are sent to relay 72, and nearly atthe same time the data units 4 and 5 are sent to relay device 73. Theroundtrip time or delay between the sender 71 and the relay device 72 ismore than twice as long as that between the sender 71 and the relaydevice 73. In the example of FIG. 7, data units 1 and 2 are lost, andonly the data unit 3 is successfully received at the relay device 72.The data units 4 and 5 are received successfully at the relay device 73before said time. In the example of FIG. 7, it is assumed that the relaydevice 72 and relay device 73 implement a missing data unit detectionfunction. Such a function indicates that a data unit is missing, if adata unit with a sequence position identifier is received, where a gapoccurs with respect to the sequence. As a consequence, the relay device73 detects data units 1, 2 and 3 as missing, because it received a dataunit with a sequence position identifier 4. As a consequence, relaydevice 73 sends a feedback message in which data units 1, 2 and 3 arenegatively acknowledged (NACK). In circumstances in which there are noparallel hops, the sending device 71 would retransmit these three dataunits immediately to the relay device 73. However, when the situation ofparallel hops can occur, it is preferable to implement a retransmitprohibit timer, which prohibits a retransmission within a given timeperiod. In the example of FIG. 7, the retransmit prohibit timer was seton the basis of the roundtrip time of the hop between sender 71 andrelay device 72. This retransmit prohibit timer expires just when thefeedback message from relay 72 arrives, in which data unit number 3 isindicated with a RACK, and data units 1 and 2 with a NACK. At this pointin time, the sending device 71 could choose to retransmit the data units1 and 2 to either relay device 72 or relay device 73. In the example,the data units are retransmitted to relay device 72.

In situations, where a peer of the inventive protocol receives dataunits from more than one peer in parallel, it is preferable thatfeedback messages are sent to all peers from which data units can bereceived. This increases the probability that the feedback informationwill arrive where it can be put to use. Nonetheless, it is naturallyalso possible to operate a peer in such a way that it only sendsfeedback messages to the peer from which it has just received a dataunit, or that the peer has a decision procedure for deciding which peerto send a feedback message to.

In the example of FIG. 7, a retransmission prohibit timer was used. Itis noted that a retransmission prohibit timer can be used in anyretransmission context, i.e. also in systems that only have individualserial hops. The retransmission prohibit timer can be triggered by aselected event, such as the transmission of a data unit and/or theretransmission of a data unit. Within the retransmission prohibit timeperiod, a retransmission is prohibited. If the peers of the presentinvention are operated such that feedback messages are sent at regularintervals, then it is preferable to employ a retransmission prohibittimer, in order to avoid unnecessary retransmissions, e.g. to avoidunnecessary retransmissions each time that a NACK is received. Whencombining a retransmission prohibit timer feature with a retransmissiontime-out feature, the retransmission time-out period (such as TO_1 orTO_2) is set longer than the retransmission prohibit period.

If a peer of the inventive protocol is able to transmit data units to atleast two different peers in parallel, then there exists a first valueindicative of a roundtrip time between the transmitting peer and thefirst peer, and a second value indicative of the roundtrip time betweenthe transmitting peer and the second parallel peer. These values couldbe fixed values, or the control unit could implement procedures fordetermining one or both of the values. The peer is arranged to employ aretransmission prohibit timer for retransmissions to said peer of thetwo parallel peers which is associated with the smaller round trip timevale. The retransmission prohibit timer is set based on the larger ofthe round trip time values.

Now, a further embodiment of the present invention will be describedwith reference to FIG. 9. FIG. 9 shows an example similar to the onediscussed in connection with FIG. 4. In accordance with an example ofthe present invention, it is possible to use the transmission state,which can also be referred to as the send window of a peer thattransmits data units as an indication for the buffer fill state in thenext peer to which data units are being sent. The send window comprisesthe sent data units, for which no feedback for a RACK has been received.As can be seen in FIG. 9, the send window at the transmitter providesinformation for a flow/congestion control decision. The active sendwindow starts above the highest accumulatively acknowledged (i.e. forwhich an ACK was received) data unit (i.e. the data unit with thehighest sequence position), and typically comprises in the lower partdata units for which a RACK has been received, or already an ACK fromthe receiver. Above there is typically a window region in which dataunits can be found for which the sender has received a RACK or a NACK.

The amount of data in the send window can therefore be viewed in threeparts:

-   -   Data units with NACK, not yet received at the next peer,        transmitter has retransmission responsibility;    -   Data units with RACK: received at the next peer, next peer has        retransmission responsibility; and    -   Data units with ACK: received at the receiver, i.e. at the        end-point, no more retransmission.

If the window is much larger than the pipe capacity and the amount ofdata units with RACK is larger than the amount of data units with NACK,then the hop following the next peer is congested, because the buffer atthe next peer has filled up. Under this condition, the peer that istransmitting should slow down its transmission rate or stop until theratio of RACKs and NACKs in feedback messages indicate that thesituation has changed.

In the above discussion it was assumed that the data units have equalsize. If the sizes differ, then the data unit size needs to be takeninto account.

As a consequence, in the general case, any peer of the inventiveprotocol that is arranged to transmit data units is preferably arrangedto keep a record of the data units which were sent and for which firsttype receipt information (RACK) has been received, and of the data unitsthat were sent and for which third type receipt information (NACK) hasbeen received. Then the transmission rate is preferably controlled basedon the relationship between an amount of data in the data units forwhich the first type receipt information has been received and an amountof data in data units for which the third type receipt information hasbeen received.

Although the present invention has been described by making reference todetailed embodiments, the scope of the present invention is not limitedto these embodiments, but much rather defined by the appended claims.Also reference signs in the claims do not limit the scope of protection,as they are only intended to make the claims easier to read.

1. A data unit sender, comprising: a data unit buffer for holding dataunits of a communication protocol, a control unit arranged to control atransmission of said data units to a peer of said communicationprotocol, a processing of feedback messages received from said peer, aretransmission of said data units based on said feedback messages, and amanagement of said buffer, and said control unit as a sending peer ofsaid communication protocol, where in accordance with said communicationprotocol said data units are arranged in a sequence and each sent dataunit is identifiable by a sequence position identifier, and saidfeedback messages, using said sequence position identifiers, carryinformation on a receipt of said data units, said communication protocolproviding for at least a first type and a second type of receiptinformation, said first type (RACK) of receipt information beingindicative of a correct receipt of a data unit at a relay peer of saidcommunication protocol, and said second type (ACK) of receiptinformation being indicative of a correct receipt of a data unit at afinal destination peer of said communication protocol, said control unitbeing arranged to perform a first retransmission control procedure for agiven data unit in said buffer that has been sent to the relay peer butfor which no first type receipt information has been received, toperform a second retransmission control procedure for said given dataunit if first type receipt information has been received for said givendata unit, and to hold said given data unit in said buffer at leastuntil having received said second type (ACK) of receipt information forsaid given data unit from the final destination peer.
 2. The data unitsender according to claim 1, wherein said first retransmission controlprocedure comprises starting to monitor a first time-out period upontransmitting said given data unit and retransmitting said given dataunit if said first time-out period passes without receiving first orsecond type receipt information for said given data unit.
 3. The dataunit sender according to claim 2, wherein said second retransmissioncontrol procedure comprises starting to monitor a second time-out periodupon transmitting said given data unit or upon receiving first typereceipt information for said given data unit, and retransmitting saidgiven data unit if said second time-out period passes without receivingsecond type receipt information for said given data unit.
 4. The dataunit sender according to claim 3, wherein said control unit is arrangedto dynamically adapt said first time-out period based on measurements ofa time that passes between a transmission of at least some of said dataunits and a receipt of respective first type receipt information, and todynamically adapt said second time-out period based on a measurement ofa time that passes between a transmission of at least some of said dataunits and a receipt of respective second type receipt information. 5.The data unit sender according to claim 1, wherein said communicationprotocol provides for a third type (NACK) of receipt information that isindicative of an incorrect receipt of a data unit at a peer of saidcommunication protocol.
 6. The data unit sender according to claim 5,wherein said first retransmission control procedure comprisesretransmitting said given data unit upon receiving third type receiptinformation for said given data unit.
 7. The data unit sender accordingto claim 5, wherein said second retransmission control procedurecomprises retransmitting said given data unit if third type receiptinformation for said given data unit has been received.
 8. The data unitsender according to claim 5, wherein said control unit is arranged tokeep a record of the data units in said buffer which were sent and forwhich first type receipt information has been received and of the dataunits in said buffer which were sent and for which third type receiptinformation has been received, and to control the transmission rate onthe basis of the relationship between an amount of data in data unitsfor which first type receipt information has been received and an amountof data in data units for which third type receipt information has beenreceived.
 9. The data unit sender according to claim 1, wherein saidcontrol unit is arranged to control the transmission of said data unitsto a first and a second peer of said communication protocol in parallel.10. The data unit sender according to claim 1, wherein said control unitis arranged to employ a retransmission prohibit timer.
 11. A data unitrelay device, comprising a data unit buffer for holding receive dataunits of a communication protocol received from a sender-side peer ofsaid communication protocol, and for holding send data units of saidcommunication protocol to be sent to a receiver-side peer of saidcommunication protocol, a control unit arranged to control a receivingof said receive data units, a transmission of said send data units, aprocessing of receiver-side feedback messages received from saidreceiver-side peer, a retransmission of said send data units to saidreceiver-side peer based on said feedback messages, a transmission ofsender-side feedback messages to said sender-side peer, and a managementof said buffer, as a relay peer of said communication protocol, where inaccordance with said communication protocol said receive data units arearranged in a sequence and each receive data unit is identifiable by asequence position identifier, and said send data units are arranged inthe same sequence such that for each receive data unit there is acorresponding send data unit having a same payload section and the samesequence position identifier, and both said sender-side and saidreceiver-side feedback messages, using said sequence positionidentifiers, carry information on a receipt of said data units, saidcommunication protocol providing for at least a first type and a secondtype of receipt information, said first type (RACK) of receiptinformation being indicative of a correct receipt of a data unit at saiddata unit relay device or a receiver-side relay peer of saidcommunication protocol, and said second type (ACK) of receiptinformation being indicative of a correct receipt of a data unit at afinal destination peer, said control unit being arranged to send asender-side feedback message to the sender-side peer carrying said firsttype (RACK) of receipt information for a given receive data unit thatwas correctly received, to perform a retransmission control process fora given send data unit in said buffer that has been sent, based on saidreceiver-side feedback message from the receiver-side peer, to hold saidgiven send data unit in said buffer until a deletion condition isfulfilled, and after having received said second type (ACK) of receiptinformation for a given sequence position identifier in a receiver-sidefeedback message from the final destination peer, to send to saidsender-side peer a sender-side feedback message carrying said secondtype (ACK) of receipt information for said given sequence positionidentifier.
 12. The data unit relay device according to claim 11,wherein said retransmission control process comprises starting tomonitor a time-out period upon transmitting said given send data unitand retransmitting said given send data unit if said time-out periodpasses without receiving second type receipt information for said givendata unit.
 13. The data unit relay device according to claim 11, whereinsaid retransmission control process comprises performing a firstretransmission control procedure for a given send data unit in saidbuffer that has been sent but for which no first type receiptinformation has been received, and performing a second retransmissioncontrol procedure for said given send data unit if first type receiptinformation has been received for said given send data unit.
 14. Thedata unit relay device according to claim 13, wherein said firstretransmission control procedure comprises starting to monitor a firsttime-out period upon transmitting said given send data unit andretransmitting said given send data unit if said first time-out periodpasses without receiving first or second type receipt information forsaid given send data unit.
 15. The data unit relay device according toclaim 14, wherein said second retransmission control procedure comprisesstarting to monitor a second time-out period upon transmitting saidgiven send data unit or upon receiving first type receipt informationfor said given send data unit, and retransmitting said given send dataunit if said second time-out period passes without receiving second typereceipt information for said given send data unit.
 16. The data unitrelay device according to claim 15, wherein said control unit isarranged to dynamically adapt said first time-out period based onmeasurements of a time that passes between a transmission of at leastsome of said send data units and a receipt of respective first typereceipt information, and to dynamically adapt said second time-outperiod based on a measurement of a time that passes between atransmission of at least some of said send data units and a receipt ofrespective second type receipt information.
 17. The data unit relaydevice according to claim 13, wherein said communication protocolprovides for a third type (NACK) of receipt information that isindicative of an incorrect receipt of a data unit at a peer of saidcommunication protocol.
 18. The data unit relay device according toclaim 17, wherein said first retransmission control procedure comprisesretransmitting said given send data unit upon receiving third typereceipt information for said given send data unit.
 19. The data unitrelay device according to claim 17, wherein said second retransmissioncontrol procedure comprises retransmitting said given send data unit ifthird type receipt information for said given send data unit has beenreceived.
 20. The data unit relay device according to claim 17, whereinsaid control unit is arranged to keep a record of the send data units insaid buffer which were sent and for which first type receipt informationhas been received and of the send data units in said buffer which weresent and for which third type receipt information has been received, andto control the transmission rate of said send data units on the basis ofthe relationship between an amount of data in send data units for whichfirst type receipt information has been received and an amount of datain data units for which third type receipt information has beenreceived.
 21. The data unit relay device according to claim 17, whereinsaid control unit is arranged such that if a receiver-side feedbackmessage is received that carries said third type (NACK) of receiptinformation for a sequence position identifier for which no data unit isstored in said buffer, a sender-side feedback message is sent thatcarries said third type (NACK) of receipt information for said sequenceposition identifier for which no data unit is stored in said buffer. 22.The data unit relay device according to claim 21, wherein said controlunit is arranged such that in response to receiving a receive data unitassociated with said sequence position identifier for which no data unitis stored in said buffer, a corresponding send data unit is sent. 23.The data unit relay device according to claim 11, wherein said controlunit is arranged such that if a receiver-side feedback message isreceived that carries said first type (RACK) of receipt information fora sequence position identifier, a sender-side feedback message is sentthat carries said first type (RACK) of receipt information for the samesequence position identifier.
 24. The data unit relay device accordingto claim 23, wherein said control unit is arranged such that saidsender-side feedback message that carries said first type (RACK) ofreceipt information for said same sequence position identifier is onlysent if there is no data unit stored in said buffer for said samesequence position identifier.
 25. The data unit relay device accordingto claim 11, wherein said deletion condition is fulfilled if said secondtype (ACK) of receipt information is received for said given send dataunit.
 26. The data unit relay device according to claim 11, wherein saiddeletion condition is fulfilled if a purge time period for said givensend data unit has elapsed.
 27. The data unit relay device according toclaim 11, wherein said control unit is arranged to control thetransmission of said send data units to a first and a secondreceiver-side peer of said communication protocol in parallel.
 28. Thedata unit relay device according to claim 11, wherein said control unitis arranged to employ a retransmission prohibit timer.
 29. A method ofcontrolling a data unit sender, which comprises a data unit buffer forholding data units of a communication protocol and is arranged to act asa sending peer of said communication protocol, where in accordance withsaid communication protocol said data units are arranged in a sequenceand each sent data unit is identifiable by a sequence positionidentifier, and feedback messages, using said sequence positionidentifiers, carry information on a receipt of said data units, saidcommunication protocol providing for at least a first type and a secondtype of receipt information, said first type (RACK) of receiptinformation being indicative of a correct receipt of a data unit at arelay peer of said communication protocol, and said second type (ACK) ofreceipt information being indicative of a correct receipt of a data unitat a final destination peer of said communication protocol, said methodcomprising the steps of: performing a first retransmission controlprocedure for a given data unit in said buffer that has been sent to therelay peer but for which no first type receipt information has beenreceived, performing a second retransmission control procedure for saidgiven data unit if first type receipt information has been received forsaid given data unit, and holding said given data unit in said buffer atleast until having received said second type (ACK) of receiptinformation for said given data unit from the final destination peer.30. The method according to claim 29, wherein said first retransmissioncontrol procedure comprises the steps of starting to monitor a firsttime-out period upon transmitting said given data unit andretransmitting said given data unit if said first time-out period passeswithout receiving first or second type receipt information for saidgiven data unit.
 31. The method according to claim 30, wherein saidsecond retransmission control procedure comprises the steps of startingto monitor a second time-out period upon transmitting said given dataunit or upon receiving first type receipt information for said givendata unit, and retransmitting said given data unit if said secondtime-out period passes without receiving second type receipt informationfor said given data unit.
 32. The method according to claim 31, furthercomprising the steps of dynamically adapting said first time-out periodbased on measurements of a time that passes between a transmission of atleast some of said data units and a receipt of respective first typereceipt information, and dynamically adapting said second time-outperiod based on a measurement of a time that passes between atransmission of at least some of said data units and a receipt ofrespective second type receipt information.
 33. The method according toclaim 29, wherein said communication protocol provides for a third type(NACK) of receipt information that is indicative of an incorrect receiptof a data unit at a peer of said communication protocol.
 34. The methodaccording to claim 33, wherein said first retransmission controlprocedure comprises retransmitting said given data unit upon receivingthird type receipt information for said given data unit.
 35. The methodaccording to claim 33, wherein said second retransmission controlprocedure comprises retransmitting said given data unit if third typereceipt information for said given data unit has been received.
 36. Themethod according to claim 33, further comprising the steps of keeping arecord of the data units in said buffer which were sent and for whichfirst type receipt information has been received and of the data unitsin said buffer which were sent and for which third type receiptinformation has been received, and controlling the transmission rate onthe basis of the relationship between an amount of data in data unitsfor which first type receipt information has been received and an amountof data in data units for which third type receipt information has beenreceived.
 37. The method according to claim 29, comprising controllingthe transmission of said data units to a first and a second peer of saidcommunication protocol in parallel.
 38. The method according to claim29, comprising employing a retransmission prohibit timer.
 39. A methodof controlling a data unit relay device that comprises a data unitbuffer for holding receive data units of a communication protocolreceived from a sender-side peer of said communication protocol, and forholding send data units of said communication protocol to be sent to areceiver-side peer of said communication protocol, and is arranged toact as a relay peer of said communication protocol, where in accordancewith said communication protocol said receive data units are arranged ina sequence and each receive data unit is identifiable by a sequenceposition identifier, and said send data units are arranged in the samesequence such that for each receive data unit there is a correspondingsend data unit having a same payload section and the same sequenceposition identifier, and both said sender-side and said receiver-sidefeedback messages, using said sequence position identifiers, carryinformation on a receipt of said data units, said communication protocolproviding for at least a first type and a second type of receiptinformation, said first type (RACK) of receipt information beingindicative of a correct receipt of a data unit at said data unit relaydevice or a receiver-side relay peer of said communication protocol, andsaid second type (ACK) of receipt information being indicative of acorrect receipt of a data unit at a final destination peer, said methodcomprising the steps of: sending a sender-side feedback message to thesender-side peer carrying said first type (RACK) of receipt informationfor a given receive data unit that was correctly received, performing aretransmission control process for a given send data unit in said bufferthat has been sent, based on said receiver-side feedback message fromthe receiver-side peer, holding said given send data unit in said bufferuntil a deletion condition is fulfilled, and after having received saidsecond type (ACK) of receipt information for a given sequence positionidentifier in a receiver-side feedback message from the finaldestination peer, sending to said sender-side peer a sender-sidefeedback message carrying said second type (ACK) of receipt informationfor said given sequence position identifier.
 40. The method according toclaim 39, wherein said retransmission control process comprises startingto monitor a time-out period upon transmitting said given send data unitand retransmitting said given send data unit if said time-out periodpasses without receiving second type receipt information for said givendata unit.
 41. The method according to claim 39, wherein saidretransmission control process comprises performing a firstretransmission control procedure for a given send data unit in saidbuffer that has been sent but for which no first type receiptinformation has been received, and performing a second retransmissioncontrol procedure for said given send data unit if first type receiptinformation has been received for said given send data unit.
 42. Themethod according to claim 41, wherein said first retransmission controlprocedure comprises starting to monitor a first time-out period upontransmitting said given send data unit and retransmitting said givensend data unit if said first time-out period passes without receivingfirst or second type receipt information for said given send data unit.43. The method according to claim 42, wherein said second retransmissioncontrol procedure comprises starting to monitor a second time-out periodupon transmitting said given send data unit or upon receiving first typereceipt information for said given send data unit, and retransmittingsaid given send data unit if said second time-out period passes withoutreceiving second type receipt information for said given send data unit.44. The method according to claim 43, further comprising dynamicallyadapting said first time-out period based on measurements of a time thatpasses between a transmission of at least some of said send data unitsand a receipt of respective first type receipt information, anddynamically adapting said second time-out period based on a measurementof a time that passes between a transmission of at least some of saidsend data units and a receipt of respective second type receiptinformation.
 45. The method according to claim 41, wherein saidcommunication protocol provides for a third type (NACK) of receiptinformation that is indicative of an incorrect receipt of a data unit ata peer of said communication protocol.
 46. The method according to claim45, wherein said first retransmission control procedure comprisesretransmitting said given send data unit upon receiving third typereceipt information for said given send data unit.
 47. The methodaccording to claim 45, wherein said second retransmission controlprocedure comprises retransmitting said given send data unit if thirdtype receipt information for said given send data unit has beenreceived.
 48. The method according to claim 45, further comprisingkeeping a record of the send data units in said buffer which were sentand for which first type receipt information has been received and ofthe send data units in said buffer which were sent and for which thirdtype receipt information has been received, and controlling thetransmission rate of said send data units on the basis of therelationship between an amount of data in send data units for whichfirst type receipt information has been received and an amount of datain send data units for which third type receipt information has beenreceived.
 49. The method according to claim 45, wherein if areceiver-side feedback message is received that carries said third type(NACK) of receipt information for a sequence position identifier forwhich no data unit is stored in said buffer, a sender-side feedbackmessage is sent that carries said third type (NACK) of receiptinformation for said sequence position identifier for which no data unitis stored in said buffer.
 50. The method according to claim 49, furthercomprising: responding to receiving a receive data unit associated withsaid sequence position identifier for which no data unit is stored insaid buffer by sending a corresponding send data unit.
 51. The methodaccording to claim 39, comprising: if a receiver-side feedback messageis received that carries said first type (RACK) of receipt informationfor a sequence position identifier, sending a sender-side feedbackmessage that carries said first type (RACK) of receipt information forthe same sequence position identifier.
 52. The method according to claim51, further comprising: only sending said sender-side feedback messagethat carries said first type (RACK) of receipt information for said samesequence position identifier if there is no data unit stored in saidbuffer for said same sequence position identifier.
 53. The methodaccording to claim 39, wherein said deletion condition is fulfilled ifsaid second type (ACK) of receipt information is received for said givensend data unit.
 54. The method according to claim 39, wherein saiddeletion condition is fulfilled if a purge time period for said givensend data unit has elapsed.
 55. The method according to claim 39,comprising controlling the transmission of said send data units to afirst and a second receiver-side peer of said communication protocol inparallel.
 56. The method according to claim 55, comprising employing aretransmission prohibit timer.